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EBCDIC/ASCLI MAPPING FOR NETWORK RJE 


INTRODUCTION, 


Under NETRJISĆ?), con's Network rje protocol(?), a virtual remote 
batch terminal may be either EBCDIC or ASCII. ССН operates an IBM 
360/91. which performs all of its normal processing in EBCDIC, When 
a virtual ASCII terminal signs onto NETRJS, CCN translates the "card 
rendey" stream to EBCDIC and translates the "printer" stream back to 
эстїї). 


In recent months, а number of ASCII hosts (RAND PDP-10, Utah PDP-10, 
Illinois PDP-11) have completed user processes for NETRIS. Several users 
ас these sites have noted deficiencies in the ASCII/EBCDIC mapping rules 
originally implemented in NETRIS. Since their objections were well 
founded, we have altered the existing mapping and added a new one. 


This RFC has three purpose! 


(1) to make all users of NETRJS aware of the changed 
ASCII mapping; 


(2) со call this problem to the attention of the Network 
RIE Protocol Comittee; 


(3) to knowledge and support Joel Winett's pioneering work‘) 
in this area. 


‘THE EBCDIC CHIMERA 


A year ago, Joel Winett published RFC #183, containing the results 
of his careful research into just what EBCDIC really means. He sounded 
a clarion call for all EBCDIC sites to join in defining a Network standard 
mapping. At that time, we at CCN were primarily absorbed in the timely 
implementation of the NETRJS protocol to serve an EBCDIC (!) user site, 
RAND, 90 we were not very supportive of his efforts. 


RFC #183 48 а valuable document; we hope a copy falls into the 
hands of Armonk. It is clear from RFC #183 that EBCDIC consists of 
a standard ("basic") set of characters, combined with a number of 
overlapping ad-hoc character happenings. Fortunately, if we exclude 
special-purpose text composition programs, IBM 360 programs use only 
the 89 "basic" EBCDIC graphics(5) shown in RFC #183 as well as in 
Figure 1. An IBM 029 "EBCDIC" keypunch can create 63 graphics: the 
89 basic EBCDIC graphics less the 26 lower case letters. In fact, 
08/360 requires an even smaller subset of EBCDIC, 60 characters 
commonly called the "PL/1 character set". The Р1/1 set consists of 
the 89 basic graphics, less the 26 lover case letters as well as the 
three graphics ¢ (cent sign, exclamation point, and quotation). 


CHARACTER MAPPING IN NETRIS 


We consider now the requirements of а ASCII/EBCDIC mapping for NETRIS 


or any rje protocol. These requirements are as follows: 


Efficiency: 


The translation should be chsracter-to-character, so that the CPU 
operation "translate" can be used and character scans obviated 
This is important because а significant volume of character data 
may be moved during rje operations. 


usability: 


(1) All of the 89 EBCDIC graphics should be mapped into 
corresponding ASCII characters. 


(2) The mapping should be as nearly transparent as possible, 
íe., whenever the sams graphic appesrs in both sets, it 
should map onto itself. 


(3) To minimize the adaptation required of an EBCDIC-oriented 
programmer, the ASCII graphics should evoke the corresponding 
EBCDIC graphic, when they are not identical. 


s considerations led us to incorporate Winett's rules IIT (a) 
and III (b) (see page 4 of RFC #183) into NETRIS: 


ASCII EBCDIC 
g 
5 ү 


\ ё 
This defines all 89 basic EBCDIC graphics in terms of ASCII. However, 
there iestill a question of how to map the 6 "maverick" ASCII characters 
«ЖИ ) which are not in EBCDIC and not in the list above. 


We could (and did) take the view that all CCN users are concerned 
only with writing and executing normal 360 programs using EBCDIC and 
that they would enter one of the maverick ASCII graphics only in error. 
Our original choice, therefore, was to map the mavericks in the input 
into EBCDIC question marks. We also assumed that, if a user needs to 
access a larger subset of EBCDIC than the basic 89, he should do so 

by doing his rje directly in EBCDIC. 


We now realize that there were two deficiencies in the original 
mapping rules. 


1. The 360 program may be intended to manipulate ASCII text 
from the Network. In that case, the Network user needs 
to have all ASCII characters, including the mavericks, 
uniquely mapped into EBCDIC in some (standard) manner, 


2. The present mapping ie convenient only if а user has a full 
ASCII terminal. In particular, а user at an AT&T Model 33 
735 Teletype (or simulator thereof) needs a different mapping 
for ease of use. 


For the first с; 
ASCII characters from 
тїї (d): 


„ уе have changed the mapping of the 6 maverick 
т", using instead Winett's rules III (с) and 


ASCIT EBCDIC 
E х'Ар' 
а Te 
{ х'ав' 
ў х'эз' 
^ x'71° 
` хит" 

For the user with a Model 33/35 Teletype, ме have expanded the set 
of virtual remote batch terminal types, adding "ITY" to "ASCII" and 
“gERCDIC". A user establishes his virtual remote batch terminal as type 
TTY by either doing his initial ICP to socket 15 (vs. 11 for EBCDIC, 

13 for ASCII), or by doing an ICP to Socket 1 and entering the command 


“ryr3s" (vs. "RIS" for EBCDIC, "ARJS" for ASCII). The mapping used by 
МЕТАЈЅ for a TTY remote site is: 


моде1 33 Corresponding 

Graphic ASCII EBCDIC 
‘N \ = 
t © \ 
sa — — 
È Е й 4 f 
a д X'BD 


This ts ugly, but 46 is probably the best we can do. 
D. CONCLUSIONS 


It is obvious that one pair of translation tables won't do the job; 
NETRIS needs (at least) two mappings for each direction, How long will 
it be before an important set of users appears wirh a different terminal 
character set, requiring yet a different mapping?©®) An rje server site 
neads to be prepared to provide a variety of translation tables, and 
perhaps to allow a user to specify his ow tuble(s); this mini-subset of 
‘Date Reconfiguration Service" might be necessary to prevent translation- 
table-proliferation. The tendency in Network discussions has been to 
put the burden upon the user sites to adapt to different conventions. 

In the real world of users and servers, the server will often have to do 
the adapting. 


E. NOTES AND REFERENCES 


. R. Т. Braden, Interim NETRIS Specifications, RFC #189 (NIC #7133), 
July 15, 1971. 


2. Please note that "RJS" 4з the proper name of а particular rje 
package written at CCN; the generic name for remote batch service 
ds "rje". 


3. Notice that the mapping question discussed in this RFC {в significant 
only for the virtual card reader and printer connections in NETRIS. 
‘The punch connection is always transparent, i.e., never translated. 
Тһе remote operator connections use the extended EBCDIC/ASCII mapping 
including the maverick characters, but this is not important since 
operator comsands require only а limited character set. 


4. Joel Winett, "The EBCDIC Codes and their Napping to ASCII", 
RFC #183 (NIC #7127), July 21, 1971. 


5. Winett lists only 88 basic EBCDIC graphies, excluding the space 
which he regards as a control character. This is а matter of 
taste, but ve find it less confusing to include the space as a 
graphic. 


6. CCN recently received а new Teletype-replecement terminal. This 
machine has a bastardized graphic character set—mostly ASCII, with 
a sprinkling of both (!) EBCDIC and TTY. 
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Figure 1., Character Sets Commonly Abused 
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